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TITLE:  Ant  mn.it  <><1  Ain'icw  Sohodu  I  i  nq  Within  the  S  t  r  .1 1  eg  i  c  • 

Air  Cmnmind:  An  I  nd  1  <  •  t  men  t  A  Solution 

AUTHOR:  Steven  G.  Joseph,  Lieutenant  Colonel,  USAF 

The  potential  for  increasing  the  effectiveness  of 

aircrew  training  within  the  Strategic  Air  Command  through 

more  effective  scheduling  is  reviewed,  and  a  case  is  made 

that  automated  assistance  is  required  to  achieve  any 

significant  improvements.  Following  an  exploration  of  the 

failure  of  the  Strategic  Air  Command  to  develop  such  a 

capability,  guidelines  for  future  development  efforts  are 

offered.  A  description  of  the  Scheduling  Assistance  System 

developed  during  the  research  as  a  feasibility  demonstration 

model  for  automated  aircrew  scheduling  is  presented.  The 

author  concludes  that  an  automated  scheduling  system  is  both 

necessary  and  feasible, 
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CHAPTER  I 


INTRODUCTION 

The  concept  of  automating  various  aspects  of  the 
aircrew  scheduling  process  has  existed  within  the  Strategic- 
Air  Command  (SAC)  for  well  over  a  decade.  In  a  1974  report 
the  idea  was  expressed  by: 

The  need  to  move  rapidly  through  a  series  of  schedules 
implies  a  heavy  computational  load  that  can  best  be  met 
by  computers.  However,  the  nature  of  the  decision  envi¬ 
ronment  with  its  large  and  complex  interrelated  set  of 
objectives  requires  a  man  to  direct  the  schedule 
building  activity.  This  man-machine  system,  with 
weights  on  objective  elements  which  can  be  varied  as 
their  effects  on  schedules  become  apparent,  implies  that 
anything  short  of  on-line  interactive  computing  will  be 
insuf f icient . 1 

Later,  in  September  1979,  the  vice  commander  in 
chief  of  SAC  directed  the  deputy  chiefs  of  staff  for 
Operations  (DO)  and  Data  Services  (AD)  to  investigate  the 
feasibility  of  applying  commercial  airline  automation 
concepts  to  the  aircrew  scheduling  problem  within  SAC.^  By 
January  1980,  Data  Automation  Requirement  (DAR)  A80-04, 
EC-135  Feasibility  Study  (later  changed  to  Crew  Scheduling 
System)  was  produced  to  develop  a  prototype  aircrew  sched¬ 
uling  system  which  would  serve  to  test  and  define  concepts 
for  eventual  command-wide  application.3  This  DAR  marked  the 
initiation  of  the  most  recent  efforts  to  apply  automation  to 
the  scheduling  process  within  SAC.  In  March  of  that  year, 
the  SAC  chief  of  staff  approved  the  project. 4 
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Meanwhile,  with  the  advent  of  the  personal  computer, 
field  units  also  recognized  that  various  functions  couid  and 
should  be  automated,  bombarding  HQ  SAC  with  numerous  re¬ 
quests  for  microcomputers  to  develop  their  own  tools  and 
solutions  to  the  problems  which  they  were  encountering.^ 
(Most  of  these  requests  were  turned  down  at  the  HQ  level 
under  the  pretext  that  such  local  efforts  would  only  dupli¬ 
cate  HQ  SAC  efforts  and  would  therefore  be  unnecessary.)^ 

With  all  this  effort,  why  is  it  that,  as  of  March 
1986,  not  a  single  piece  of  hardware  or  software  has  been 
fielded  under  the  aegis  of  automated  aircrew  scheduling? 
Why  has  the  project  failed  so  miserably?  Is  it  a  valid 
requirement?  Is  there  a  solution  and,  if  so,  what  is  it? 

This  report  attempts  to  answer  these  questions  by 
first  identifying  the  need  for  an  automated  aircrew  sched¬ 
uling  system.  it  then  examines  the  reasons  for  the  failure 
of  the  current  efforts  to  produce  anything  useable,  and 
provides  guidelines  for  further  efforts. 

However,  the  primary  thrust  of  this  research  project 
has  been  the  development  of  the  Scheduling  Assistance  System 
(SAS) ,  a  comprehensive  set  of  computer  programs  for  the 
automated  generation  and  evaluation  of  aircrew  training 
schedules.  Chapter  V  describes  the  capabilities  of  SAS  in 
some  detail,  while  comprehensive  User's  Guides  are  provided 
under  separate  cover. 


CHAPTER  II 


WHY  AUTOMATED  SCHEDULING  ASSISTANCE? 

The  primary  function  of  scheduling  in  a  typical  SAC 
wing  is  to  provide  trained,  mission  ready  crews,  capable  of 
fulfilling  their  wartime  tasking.  More  specifically,  sched¬ 
ulers  are  charged  with  the  responsibility  of  ensuring  that 
all  training  requirements  for  aircrews  and  aircrew  members 
are  scheduled  so  as  to  satisfy  the  minimum  requirements 
established  in  the  applicable  SAC  51-series  regulations.^ 
These  regulations  specify  the  minimum  volume  and  frequency 
of  accomplishment  of  numerous  training  events  known  as 
command  directed  events  (CDEs)  as  well  as  unit  unique  events 
called  wing  directed  events  (WDEs). 

This  is  generally  accomplished  by  the  development  of 
quarterly  training  plans  which  are  further  refined  to 
monthly  operations  plans  (MOPs)  and  finally  to  weekly  flying 
sc'  .Jules.  Training  missions  or  sorties  are  developed  and 
distributed  among  crews  in  an  attempt  to  satisfy  the 
training  requirements.  Of  necessity,  sorties  are  inter¬ 
spersed  among  periods  of  ground  alert,  combat  crew  rest  and 
recuperation  (CCRR)  following  alert,  leaves  and  TDY.  Ground 
training  requirements,  such  as  simulators,  life  support 
training,  flight  physicals,  physiological  training,  etc. 
must  also  be  worked  into  the  schedule.  in  short,  the  sched¬ 
uler's  function  is  to  match  resources  with  requirements. 


Training  Accomp 1 1 s hmen t 

Daring  1984  and  1985  the  Training  Management  Infor¬ 
mation  Branch,  HQ  SAC/DOTFT,  produced  a  set.  of  exhaustive 
Aircrew  Training  Reports  (ATRs)  which  examined  B-52,  KC-i35 
and  FB-111  aircrew  continuation  training.^  Bach  flying 
training  event  was  examined  in  considerable  detail.  One 
particular  measure,  the  individual  completion  rate  (!.0R),  is 
especially  pertinent.  The  ICR  of  a  particular  C 1 ) K  is  the 
percentage  of  crew  members  who  have  satisfied  the  minimum 
currency  and  volume  requirements  of  the  applicable  SAC  51- 
series  regulation.  For  example:  If  the  requirement  for 

sorties  is  ten  per  quarter,  and  all  crew  members  achieve 
nine,  the  ICR  is  zero  since  not  a  single  crew  member 
satisfied  the  minimum  requirement.  The  ICR  for  a  frequency 
event  was  computed  by  examining  the  percentage  of  crew 
members  who  were  overdue  or  delinquent  on  the  last  day  of 
the  training  period. 

TABLK  I 

PERCENT  OF  TRAINING  ITEMS  WITH  ICR  BELOW  85 


ACFT 

3/84 

4/84 

1/85 

2/85 

B-52 

59.8 

57.6 

48.9 

43 . 3 

KC- 135 

19.0 

20 . 3 

24.6 

23 . 2 

FB-111 

17.0 

15.1 

11.3 

3.8 

NOTE  1: 

Only  mission 

qualified 

crew  members 

i nc 1 uded . 

NOTE  2: 


Contingency  training  events  not  included. 


An  ICR  below  85  was  used  by  HQ  SAC/DOT  for  purposes 
of  identifying  potential  problem  areas.  The  preceding  table 
depicts  the  percentage  of  CDEs  which  fell  into  the  problem 
category  for  a  one  year  cycle.  As  is  readily  evident,  B-52 
aircrews  experience  significant  difficulty  in  achieving 
satisfactory  training  rates.  This  factor  has  import  later 
in  this  report.  There  are  several  reasons  which  contribute 
to  the  low  B-52  ICRs.  These  include: 

low  sortie  production  rates 
-  poor  distribution  of  scheduled  activity 

aircraft  modification  and  conversion  programs 
insufficient  training  opportunity 
higher  headquarters  directed  ( HHD)  exercises 
crew  member  inattention  to  51-series  requirements 
While  unit  schedulers  have  little  or  no  control  over 
several  of  these  factors,  sortie  distribution  and  training 
opportunity  are  specific  responsibilities.  It  is  also  the 
scheduler's  responsibility  to  mitigate  the  adverse  impacts 
of  external  influences. 

Although  several  CDEs  were  identified  as  having  low 
ICRs  command-wide,  the  ICRs  for  the  same  event  varied 
greatly  among  individual  units.  This  tends  to  confirm  the 
idea  that  different  units  have  better  schedulers.  It  also 
suggests  that  improved  scheduling  practices,  even  manual, 
can  result  in  improved  training  rates,  especially  among 
those  units  on  the  lower  end  of  the  spectrum. 3 


Another  way  of  Looking  at  these  Low  training  rates 
is  to  consider  the  Lost  opportunity  costs  of  ma  1  d  i  str  1  buted 
training.  To  achieve  a  L  percent  improvement,  would  require 
roughly  a  1  percent  increase  in  f Lying  hours  and  sorties. 
If  the  same  improvement  can  be  achieved  through  better 
scheduling,  the  net  result,  with  B-52  annual  flying  hour 
costs  in  excess  of  800  mi  L  L  ion  dollars,  is  an  annual  produc- 
t  i  v  i  ty  enhancement  worth  eight  million  dollars.1^  One  study 
has  suggested  that  a  7  to  10  percent  improvement  is 
realistic.5  To  this  point,  an  argument  has  boon  made  ttaat 
B-52  units  are  not  achieving  satisfactory  training  rates, 
that  improvements  can  be  made,  and  that  the  lack  of  improved 
scheduling  is  costly,  yet  these  factors  alone  do  not  dictate 
an  automated  solution. 

Turning  to  the  computational  aspects  of  the  sched¬ 
uling  problem,  consider  the  number  of  data  elements  which 
need  to  be  examined  in  a  typical  B-52  unit.  For  this  compi¬ 
lation  an  OAS/ALCM  equipped  B-52  unit  with  21  authorized 
crews  and  no  contingency  taskings  is  used.  Only  command 
directed  flying  training  events  for  mission  qualified  (line) 
crews  and  crew  members  are  considered.  The  table  below, 
based  on  SACR  51-52  requirements,  depicts  the  type  and 
number  of  data  elements  which  must  be  considered  by  the 
scheduler,  but  is  by  no  means  a  complete  listing. ^ 
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TABLE  I  I 


SCHEDULING  DATA  ELEMENTS 


‘Number  of  events  requited  237 

♦Number  of  events  accompl  i shed/rema  i  n i  ng  237 

Number  of  times  scheduled  237 

♦Date  last  accomplished  43 

♦Date  due  43 

Date  next  scheduled  237 

Attrition  factor  (loss  rate)  per  event  86 

1120 

Times  21  crews  x  2 1 

Total  23520 


*  I  tern  tracked  by  AFORMS 

Add  to  this  total  unit  requirements,  ground  training 
requirements,  alert,  leave,  flight  physicals,  HHD  taskings, 
DNIF/DNIA,  staff  flying,  upgrade  training,  etc.,  and  the 
number  of  individual  data  elements  to  manage,  examine, 
analyze  and  weigh  far  exceeds  the  capabilities  of  manual 

7 

data  management. 

Some  automated  assistance  is  provided  by  the  Air 
Force  Operations  Resource  Management  System  (AFORMS).  This 
on-line  system  tracks  training  accomplishments  and  identi¬ 
fies  training  remaining.  Essentially  a  bookkeeping  system, 
AFORMS  has  no  capability  to  generate  a  schedule  or,  for  that 
matter,  to  evaluate  the  effectiveness  of  a  manually  produced 
schedu  le . 

It  is  specifically  in  the  area  of  schedule  genera¬ 
tion  and  evaluation  that  an  automated  capability  is  needed, 
a  need  identified  as  early  as  1974,  and  regularly  reaffirmed 
by  unit  schedulers. 


CHAPTER  III 


WHAT  WENT  WRONG? 

Before  outlining  a  solution  to  the  aircrew  sched¬ 
uling  problem,  it  is  important  to  review  the  failures  asso¬ 
ciated  with  the  effort  which  began  in  1979  for  two  reasons. 
The  first  is  to  avoid  revisiting  the  mistakes  of  the  past; 
the  second,  to  refute  the  notion  that  further  attempts  to 
automate  the  scheduling  process  are  too  costly.^ 

The  Wrong  Problem 

One  of  the  major  deficiencies  of  the  current  effort 
was  the  failure  to  identify  and  articulate  improved  training 
effectiveness  and  resource  utilization  as  the  primary  goal 
of  the  project.  As  noted  previously,  the  training  of  B-52 
aircrews  to  the  minimum  requirements  of  the  command  has  been 
less  than  satisfactory.  But  the  document  which  was  to  guide 
the  development  of  the  project,  the  functional  description 
(FD) ,  only  addressed  the  difficulties  of  the  scheduler's 
task  and  that  the  proposed  system  would  make  life  easier. 
Quoted  below  is  the  complete  description  of  deficiencies  of 
the  current  manual  system  and  the  improvements  which  were  to 
be  gained  from  the  new  system. 


2.3.e  Deficiencies:' 


(1)  Time  Delays.  The  scheduling  process  is  very 
time  consuming,  requiring  the  services  of  about  two  full 
time  schedulers  per  flying  squadron  in  SAC.  Adding  to 
the  task  is  the  fact  that  flying  schedulers  must  be 
highly  responsive  to  outside  influences,  such  as  air¬ 
craft  aborts,  weather,  aircrew  illness,  etc.  Such 


outside  influences  commonly  require  the  scheduler  to  re¬ 
build  the  schedule  completely  to  accommodate  a  small 
change.  Small  changes  often  have  the  effect  of  rippling 
through  a  schedule,  causing  massive  numbers  of  other 
changes.  Adding  to  the  scheduler's  task  is  the  fact 
that  he/she  must  produce  weekly,  monthly,  quarterly,  and 
in  some  cases  semi-annual  or  annual  schedules,  called 
training  plans.  The  current  system  is  often  not  able  to 
respond  to  the  immediate  needs  of  wings,  when  outside 
influences  necessitate  changes  in  the  schedule. 


(2)  Administrative  Workload.  Whenever  a  small 
change  causes  other  changes  in  a  schedule,  a  large 
amount  of  paperwork  is  involved.  New  schedules  must  be 
typed,  reproduced  and  distributed.  New  flight  orders 
must  be  typed  and  signed. 


2.4.1  Summary  of  Improvements 


a.  Functional  Improvements:  Scheduling  functions 
would  consist  of  initial  input  into  the  system, 
updating,  changing,  deleting,  extracting  formatted  data 
in  the  quantity  desired  for  distribution.  Schedulers 
would  no  longer  have  to  build  schedules,  their  only 
function  in  that  respect  would  be  to  keep  the  data  base 
updated  with  current  data,  and  monitor  the  system  for 
malfunctions  or  possible  errors.  However,  the  human 
element  of  the  decision-making  process  must  remain 
intact  to  permit  deviation/unscheduled  occurrences  when 
or  should  they  arise. 


b.  Better  Balancing:  This  system  will  have  the 
capabilities  to  instantly  produce  the  units  flying  hour 
consumption  versus  the  allocation.  This  data  would  be 
accurate  to  the  day  and  time  of  the  last  mission  flown 
for  a  given  day  or  the  current  quarter  at  the  time  of 
request.  Units  will  also  have  the  capability  of 
reviewing  flying  hour  accomplishments  for  the  entire 
fiscal  year  on  a  moment's  notice.  Schedulers  would  no 
longer  need  computer  products  from  the  Operations  System 
Management  (OSM)  Branch.  They  need  only  query  the 
system  for  individual  crew  training  events 
accomplished/remaining;  qualification  checks,  physicals, 
etc.  The  CRT  device  will  permit  review  of  the  data  on 
screen  and  provide  a  copy  of  the  displayed  data  if 
des i red . 


c.  Timeliness:  The  present  scheduling  method  requires 
10  duty  days  to  construct  a  monthly  flying  schedule. 
The  inception  of  the  new  system  would  reduce  the  buil¬ 
ding  process  to  a  matter  of  hours.  Compiling  data  is 
also  time  consuming.  The  scheduler  must  compile,  then 
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sort  the  various  media  of  data  received  prior  to  per¬ 
forming  the  functions  of  scheduling.  However,  more  time 
savings  wi  1  1  be  made  under  the  new  system  by  allowing 
the  scheduler  to  input  and  store  data  on  file  as  it  is 
received  or  at  his/her  leisure.  Once  all  the  required 
taskings  are  on  tile,  the  scheduler  merely  initiates  an 
"Initial  Schedule  Build"  statement.  This  statement 
tells  the  system  to  activate  the  SACARMS  data  base  and 
compiled  taskings  already  stored  on  file.  The  inter¬ 
actions  of  these  activities  will  create  a  reliable  and 
accurate  schedule  with  all  the  available  current 
i n  forma t ion . 

d.  The  CRT  device  and  schedules  stored  on  disk  wi 1 1 
eventually  eliminate  the  need  for  the  "grease  board" 
currently  found  in  the  55  SRW  scheduling  shop. 

Note  that  the  deficiencies  of  the  current  system  and 
the  improvements  to  be  gained  by  the  automated  system  are 
administrative  and  time  oriented.  This  is  in  direct  con¬ 
trast  to  the  Rand  approach,  which  concentrated  ".  .  .  on 
payoff  in  terms  of  training  effectiveness,  sorties,  and 
resource  use,  not  on  making  the  scheduler's  life  easier."4 

The  Wrong  Prototype 

DAR  A80-04  called  for  a  prototype  system  to  be 
developed  for  the  EC-135  operation  of  the  55  Strategic 
Reconnaissance  Wing  (SRW)  collocated  with  HQ  SAC  on  Offutt 
AFB.  Later,  before  the  functional  description  was  fin¬ 
alized,  the  prototype  was  shifted  to  the  E-4A  operations  of 
the  1st  Airborne  Command  Control  Squadron  (1  ACCS).  Neither 
of  these  units  are  typical  of  other  SAC  units,  with  the  E-4A 
perhaps  the  most  atypical  unit  of  all. 

As  discussed  in  the  preceding  chapter,  SAC  B-52 
units  have  the  greatest  difficulty  in  meeting  training 
requi  remen  t:;. 


thus  to  have  significant  payoff,  B-52  units 
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Jill  oil  !  <1  be  pi  •  >  I  <  >  l  y  |  >  c  ■  <  1  -  -nut  .1  unit  or  ,ji  rrr.if  t  which  has 
little  problem  achieving  its  requirements. 

The  seeming  expedience  of  using  an  on-base  unit, 
merely  because  it  was  close  at  hand,  could  only  guarantee 
that  automation  was  being  applied  to  an  area  which  did  not 
really  need  help--nor  could  a  solution  to  that  unit's 
problem  necessarily  be  applied  command-wide. 

Lack  of  Scheduling  Experience 

Perhaps  the  single  greatest  failure  evident  in  the 

project  definition  phase  was  the  lack  of  involvement  of 

individuals  with  scheduling  experience  and  expertise.  As  a 

result,  the  functional  description  described  a  scheduling 

process  and  set  of  decisions  which  may  have  appeared 

logical,  but  which  reflected  neither  reality  nor  SAC  policy. 

The  FD  was  a  reflection  of  the  aircrew  scheduling  process  as 

seen  by  a  crew  member  who  is  familiar  with  only  the  final 

steps  of  schedule  development.  For  example,  in  describing 

the  existing  methods  and  procedures,  the  FD  states:** 

2. 3. a  There  is  no  standard  Air  Force  means  of  sched¬ 
uling  aircrews  or  individuals.  Each  MAJCOM  has  a  unique 
training  management  system  that  aids  scheduling. 
However,  most  MAJCOMs  use  a  general  scheduling  system 
that  involves  a  cycle  of: 

(1)  Fly  the  sortie. 

(2)  Log  the  training  accomplished. 

(3)  Input  the  data  into  a  computer. 

(4)  Computer  compares  the  accomplishments  versus 

requirements  to  obtain  training  remaining. 

1  1 


(5)  Schedule  next  sortie  leseii  largely  on  truimn; 

remaining. 

(6)  Mission  plan  the  sortie. 

(7)  Fly  the  next  sortie,  etc. 

While  this  appears  to  be  a  quite  reasonable  s*  lied  - 
uling  process,  it  is  quite  wrong.  The  most  critical  phase 
in  building  a  schedule  is  in  the  planning  phase,  where  a 
quarterly  schedule  is  developed.  The  scheduler  begins 
sever-i  1  weeks  before  the  start  ot  a  training  period  (a  three 
month  quarter  in  SAC)  and  lays  out  al  1  known  task inqs  such 
as  alert,  leave,  TDY,  HH1),  training  requirements,  etc. 
Concurrently,  after  discussion  with  squadron  operations 
personnel  and  other  wing  level  staff  agencies,  a  set  of 
mission  profiles  is  developed  which  satisfies  unit  emphasis 
on  such  items  as  night  training,  low  level  diversity,  etc. 
These  mission  profiles  are  then  coordinated  with  maintenance 
aircraft  schedulers  to  assure  that  takeoff  and  landing 
times,  sortie  durations,  sorties  per  week,  etc.,  can  be 
supported.  Refinements,  compromises  and  adjustments  un¬ 
made  so  that  the  aircraft  flow  and  sortie  flow  are  in 
concert.  Only  then  is  the  scheduler  prepared  to  assign 
sorties  to  crews.  The  resultant  quarterly  plan  is  then 
refined  on  a  monthly  basis  for  production  of  the  monthly 
operations  plans. 

Final ly,  during  the  execution  phase  of  the  plan, 
adjustments  are  made  on  a  weekly  and  daily  basis.  Most 
training  requirements  are  actually  given  secondary 
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consideration  <it  this  point,  with  ct..*w  mcmbct  substitut 


maintenance  and  weather  impacts  taking  priority.  Virtually 


the  only  training  requirements  which  i  r .  •  considered  in  this 


execution  phase  are  currency  or  readiness  items  which  would 


prevent  a  crew  member  from  assuming  alert. 


It  is  the  attention  to  the  quarterly  plan  that 


spells  the  success  or  failure  of  the  schedule  (in  terms  of 


effectiveness),  not  daily  or  weekly  scheduling.  Consider 


the  guidance  published  in  SACR  60-9,  Planning  and  Scheduling 


Aircrew  and 


The  quarterly  plan  is  the  key  to  a  good  unit  schedule.  . 
.  .  Operations  and  raintenance  schedulers  must  recognize 
the  importance  of  quarterly  planning  to  ensure  the 
framework  for  an  effective  monthly  plan  and  weekly 
schedule  is  started  during  the  development  of  the 
quarterly  plan.  The  quarterly  plan  begins  when  the  unit 
receives  the  Flying  Program  Document  (FPD) .  This  docu¬ 
ment  will  arrive  at  the  unit  seven  weeks  before  the 
quarter . 6 


Critical  to  the  discussion  above  is  that  an  algo¬ 


rithm  based  on  the  f  1  y-schedu  1  e- f  1  y  concept  is  not  the  same 


as  one  based  on  quarterly  planning.  Hence  the  algorithm  and 


computer  program(s)  developed  thereupon  will  not  support  the 


scheduling  process  as  it  is  practiced  and  directed. 


The  treatment  of  ground  scheduling  with  the  same 


priority  and  attention  as  flight  scheduling  is  another 


example  where  the  FD  is  at  odds  with  scheduling  realities. 


While  these  items  are  essential,  in  reality,  they  are  rela¬ 


tively  easy  to  schedule,  with  the  majority  of  ground 


training  conducted  while  crew  members  are  on  alert, 


w! 


f 

•'*•1 


I 

% 

Sw 


Failure  to  Address  Existing  Capabi 1 i t  x  e  s 

Despite  the  shortcoininys  of  the  document,  the  FD  did 
insist  that  any  system  must  interface  with  the  existing 
lutomated  support  systems--the  SAC  Aircrew  Resource  Manage¬ 
ment  System  (SACARMS),  and,  later,  AF0RMS.7  These  systems 
are  essentially  bookkeeping  systems  which  track  crew  member 
training  requirements  and  accomplishments.  They  provide  a 
great  deal  of  the  historical  information  on  which  scheduling 
decisions  are  based. 

Yet  programmers  charged  with  developing  the  aircrew 
scheduling  system  simply  failed  to  learn  and  understand 
these  systems  and  the  data  bases  which  supported  them.  As  a 
result,  the  only  software  ever  produced  by  the  AD  community 
in  support  of  automated  aircrew  scheduling  was  a  rather 
limited  data  base  update  capability  which,  when  presented  in 
May  1983,  was  quickly  rejected  since  it  could  not  even 
closely  approach  the  capability  of  AFORMS  which  had  been 
fully  implemented  at  Offutt  two  months  previously. 8 

Project  Management 

Throughout  the  numerous  letters,  memoranda,  trip 
reports  and  staff  summary  sheets  reviewed,  two  common 
threads  appear-- interagency  bickering  and  a  lack  of  account¬ 
ability,  responsibility  and  authority. 


Within  only  a  lew  days  of  the  chief  of  staff's 
approval  of  the  project,  a  rift  developed  between  the  AD  and 
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DO  community,  initiated  by  a  DO  request  to  include  oimput.  ■  -r 
programmers  within  the  VilJRW  Provisional  s  c  h .  ■  <  1  u  1  i  n  . 
Section1-1.  Alter  a  three  month  exchange  ot  M  i  .'is,  the 
issue  was  eventually  dropped.  But  manning  was  only  one  o! 
several  issues. 

The  two  communities  consistently  infringed  upon  the 
other's  perceived  functional  area  of  responsibility.  Thus 
AD  took  umbrage  whenever  the  DO  community  developed  specific 
architectural  requirements  such  as  mass  storage  and  memory 
size  and  other  hardware  requi rements. On  the  other  hand, 
the  AD  community  continually  attempted  to  roll  all  DO  auto¬ 
mation  requests  under  a  single  umbrella  project. H  These 
attempts  were  seen  by  DO  as  delaying  tactics  to  avoid  not 
only  the  scheduling  project,  but  several  other  short  term 
initiatives,  which  although  they  may  have  addressed  certain 

aspects  of  aircrew  training,  such  as  flight  planning,  were 

.  1  ? 

not  directly  related  to  the  project  at  hand. 

On  reflection,  much  of  this  bickering  seems  to  have 
resulted  from  a  lack  of  analytical  expertise  in  either  camp. 
Analysis,  as  used  here,  refers  to  the  rather  specific, 
technical  function  of  translating  the  human  scheduling  and 
dec i s i on-mak i ng  processes  into  a  set  of  algorithms  from 
which  a  programmer  can  then  generate  the  computer  code  to 
replicate  these  processes.  This  field,  often  called 
operations  research  or  operations  analysis,  requires  actual 
technical  expertise  and  training,  not  just  the  appendage  of 


the  word  "analyst"  to  a  duty  title.  Without  soinoon.- 
fulfilling  this  function,  the  ‘jap  between  operational 
requirements  and  the  computer  programs  to  support  them  could 
not  be  br ldged. 

Accountabi 1 i ty ,  Respons i bi 1 1 ty  and  Authority 

From  both  personal  observation  and  a  review  ol  the 
literature,  it  was  fairly  obvious  that  no  one  individual  o  ; 
agency  was  ever  assigned  real  responsibility  for  the  suc¬ 
cessful  conclusion  of  the  project.  Although  project 
officers  were  assigned  by  both  Al)  and  DO,  they  were  neither 
dedicated  to  the  aircrew  schedul  ing  project  nor  were  they 
held  accountable  for  success,  failure  or  progress.  The 
colonel  level  steering  group  met  only  once  or  twice  in  the 
early  stages,  while  working  groups  were  sporadically  formed 
for  a  short  spurt  of  activity  before  quickly  fading  away. 

As  with  responsibility  and  accountability,  authority 
was  never  entrusted  to  a  single  individual  or  agency.  As  a 
result  numerous  impasses  were  never  resolved,  with  each 
agency  doing  what  they  saw  lit. 

Post  Mortem 

The  automated  aircrew  scheduling  project  has  made 
little  progress  since  its  inception  in  1979.  The  project 
did  not  fail  because  it  was  too  complex  or  difficult,  not 
because  of  any  single  agency  or  individual,  but  rather  (in¬ 
to  a  comb i n  a  t i o  n  of  several  i  tern  s  which  fell  into  tw> 
categories,  project  management  and  project  execution. 


Project  management  was  characterized  by  a  failure  to 
(.•stab  1  i  sh  clear  cut  authority,  responsibility  and 
a  ;  ■  co  u  n  t  a  b  i  1  i  t  y .  As  a  result,  interagency  t>  ickorin  j  w  is 
rampant.  The  necessary  manpower  w .  i  s  diluted  among:,' 
unrelated  projects,  appropriate  scheduling  and  analytical 
expertise  was  not  provided  and  project  definition  was  never 
satisfactorily  completed. 

Project  execution,  the  technical  portion  of  the 
project,  was  hampered  by  the  failure  to  understand  and 
define  the  scheduling  process.  This  led  to  the  development 
of  a  functional  description  of  an  overly  complicated  solu¬ 
tion  to  the  wrong  problem  for  the  wrong  reason.  A  lack  of 
analytical  expertise  failed  to  produce  workable  algorithms, 
while  a  lack  of  knowledge  of  existing  capabilities  and 
systems  led  to  unnecessary  duplication  of  data  base  design. 


CHAPTER  IV 


SOME  BASIC  GUIDELINES 

Tills  chapter  suggests  some  basic  aside  I  iivs  lot  the 
future  development  of  any  automated  aircrew  sc  tie  da  1  1  no 
system.  Derived  from  the  lessons  of  the  [last,  they  a. 
neither  all-inclusive  nor  are  they  revolutionary. 

Projec t  Management 

Program  Director 

Establish  the  Director  of  Tr  lining  (DOT)  as  the 
program  director.  The  responsibility  for  developing  and 
managing  aircrew  training  programs,  schedulin')  policy,  low 
level  training  routes,  the  SAC  flying  hour  program  and 
AEORMS  all  resides  with  the  DOT.  It  is  DOT  needs  ind 
requirements  which  are  to  be  satisfied.  Implicit  in  i  he 
acceptance  of  responsibility  is  the  authority  to  resolve 
conflicts  and  impasses  when  they  develop.  General  officer 
involvement  should  not  be  required  for  conflict,  resolution, 
but,  if  so,  the  final  arbiter  must  be  the  Deputy  Chief  of 
Staff,  Operations  (DO). 

R  e s  pons i b i 1 i t ies 

DOT  responsibilities  include  the  definition  of 
requirements  which  the  system  must  satisfy,  the  development 
of  appropriate  algorithms,  provision  of  functional  area 
expertise,  and  test  and  evaluation  o 1  any  software. 
Information  Systems  (SI)  responsibilities  are  to  provide 


hardware,  develop  software  and  to  assist  in  developing 
appropr  i  ate  a  l<jor  i  thins.  ^ 

Development  of  algorithms  is  seen  as  a  DOT  responsi¬ 
bility  since  they  must  reflect  scheduling  processes  and 
policies,  not  those  of  data  automation. 

Organization 

Within  DOT,  program  management  should  be  assigned  to 
the  training  division  (DOTT)  since  that  division  is  respon¬ 
sible  for  aircrew  training,  scheduling  policy  and  unit  level 
DO  organization.  The  operations  systems  management  division 
( DOT  F )  must  be  closely  involved  due  to  its  functional 
responsibility  for  AFORMS.  A  separate  DO  organization 
outside  of  DOT  should  not  be  established. 

Within  SI,  primary  responsibility  rests  with  the 
support  programming  division  (SIUS).  This  division  has 
responsibility  for  developing  SAC  unique  enhancements  to 
AFORMS,  and  had  previously  developed  SACARMS  and  the  SACARMS 
to  AFORMS  conversion  program. 

Mann i ng 

DOT  manpower  assigned  to  this  project  should 
include,  as  a  minimum,  one  officer  with  extensive  B-52 


scheduling  experience  and  expertise;  one  officer  or  civilian 
with  an  operations  analysis  background;  and  one  NCO  with 
extensive  AFORMS  experience.  These  individuals  must  be 
dedicated  to  the  aircrew  scheduling  project  from  the  defini¬ 
tion  through  validation  phases.  Key  is  the  selection  of  the 


schedu  1  1  ny  officer,  who  must  he  selected  bused  on  schedu  1  in  , 
expertise,  not  for  computer  literacy  or  "promotabi 1 ity." 

SLU  manpower  must  i nc  1  tuie  programmers  conversant 
with  the  AFORMS  data  base,  the  base  level  computer  system 
and  microcomputers.  Microcomputer  expertise  is  requir'd 
since  a l 1  SAC  schedu liny  offices  have  m  l  croeomput et s  which 
function  as  AFORMS  terminals  into  the  base  level  ma < n f r am.  ■ . 
Progress  Evaluation 

DOT  must  establish  a  set  of  appropriate  milestones 
for  measuring  progress.  Milestones  should  be  established  on 
a  fairly  aggressive  schedule  in  order  to  avoid  diminution  of 
resources  and  effort.  Project  reviews,  chaired  by  the  DOT, 
should  be  conducted  at  each  major  milestone,  but  not  less 
than  quarterly. 

Test  and  Evaluation 

Field  evaluation  by  unit  schedulers  is  critical 
since  they,  not  HQ  SAC,  are  the  users  of  the  system.  This 
does  not  alleviate  SAC/DOT  responsibility  for  rigorously 
testing  all  software  prior  to  field  trials. 

Development  Guidelines 
Concentrate  on  Effectiveness 

During  the  critical  definition  phase,  concentration 
must  remain  focused  on  increasing  training  effectiveness, 
not  on  making  the  scheduler's  task  easier.  Conversely, 
automation  should  not  make  the  task  more  difficult.  Big 
payoff  items  should  be  addressed  first,  specifically  the 
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quarterly  plunninq  process.  Avoid  the  tendency  to  automate 
processes  which  provide  only  marqinal  improvements  simply 
because  they  are  easy  to  do  and  <jive  an  impression  of 
progress . 

Focus  on  B-52  Scheduling 

Since  B-52  training  rates  clearly  have  the  greatest 
potential  for  improvement,  they  also  have  the  greatest 
payoff  potential.  Algorithms  can  become  unwieldy  or  ex¬ 
ceedingly  complex  when  attempting  to  satisfy  everyone.  When 
this  occurs,  solve  the  B-52  problem  first. 

Interface  AFORMS  Early 

A  great  deal  of  the  historical  and  bookkeeping 
information  necessary  for  effective  scheduling  is  contained 
in  the  AFORMS  system.  A  terminal  resides  in  every  sched¬ 
uling  office  and  tactical  squadron.  Duplicate  data  bases, 
and  more  specifically,  duplicate  data  entry,  should  not  be 
tolerated. 

Use  Existing  Hardware 

The  system  should  be  designed  to  use  the  hardware 
already  in  place.  Specifically,  the  Sperry  1100  base  level 
mainframe  system  and  the  Sperry  PC  microcomputer.  These 
systems  have  only  recently  been  fielded  by  the  Air  Force  and 
will  be  around  for  some  time.  Attempts  to  purchase  addi¬ 
tional  or  separate  systems,  such  as  minicomputers,  will  only 
cause  endless  delays  in  actually  fielding  a  useful  product. 


as  well  as  distracting  project  personnel  from  the  primary 
task  at  hand. 

BuiLd  Tools 

A  computer  program  is  nothing  more  than  a  tool. 
Some  tools,  such  as  word  processing  programs,  are  extremely 
useful  when  dealing  with  textual  data,  but  are  of  little 
utility  in  an  accounting  role--for  which  other  tools  have 
been  developed.  This  same  concept  applies  to  aircrew 
scheduling.  One  tool  may  be  useful  for  generating  a  quar¬ 
terly  plan,  another  for  evaluation  of  that  plan,  and  yet 
another  for  weekly  scheduling.  Thus,  rather  than  attempting 
to  design  and  build  one  all-encompassing  system,  build  a  set 
of  tools,  each  designed  for  a  specific  task. 

Perfection  is  Not  a  Requirement 

A  scheduling  tool  does  not  have  to  perform  an  entire 
task  in  order  to  be  valuable.  A  schedule  generation 
program,  for  example,  which  only  generates  a  flying 
schedule,  but  not  a  ground  training  schedule  it  still 
useful,  despite  the  fact  that  ground  training  items  are  not 
scheduled  automatically.  Systems  should  be  designed  and 
evaluated  not  on  how  much  of  the  task  they  can  perform,  but 
rather  on  how  they  improve  training  and  scheduling 


effectiveness . 


THE  SCHEDULING  ASSISTANCE  SYSTEM 


The  primary  purpose  of  this  research  effort  has  been 
the  development  of  the  Scheduling  Assistance  System  (SAS)  as 
a  feasibility  demonstration  model  for  future  development. 
SAS  comprises  a  set  of  several  computer  programs  which  are 
designed  to  provide  Strategic  Air  Command  aircrew  schedulers 
with  a  set  of  tools  to  help  build  and  evaluate  aircrew 
training  plans  early  in  a  training  period  and  subsequently 
make  the  necessary  mission  and  training  adjustments  early, 
thereby  contributing  to  schedule  stability  as  well  as 
consistently  high  training  rates. 

Background 

Historically,  SAS  evolved  from  a  precursor  system 
called  DOTARMS  (DOT  Aircrew  Resource  Management  System), 
which  was  developed  by  the  author  while  serving  as  the 
Director  of  Training  at  the  92nd  Bomb  Wing,  Fairchild  AFB, 
WA.  The  initial  system  was  designed  to  evaluate  the  effec¬ 
tiveness  of  a  manually  produced  aircrew  training  schedule 
and  to  identify  potential  training  shortfalls.  An  initial 
set  of  programs  was  developed,  using  solely  in-house  compu¬ 
ter  programming  capability,  which  verified  the  concept. 

That  initial  program  set  has  been  expanded  and 
revised  considerably.  AFORMS  ID  numbers  and  codes  have  been 
incorporated  rather  than  the  codes  used  in  the  now  obsolete 


SACARMS  system.  The  initial  sequential  file  access  routines 
have  been  replaced  with  substantially  faster  direct  access 
routines.  A  menu-driven  front  end  has  been  added  which 
directs  execution  of  all  other  programs,  as  well  as  loading 
numerous  common  constants  which  assists  in  speeding  up 
operation.  In  addition,  the  entire  system  has  been 
"universalized"  to  accept  most  SAC  aircraft.  That  system  is 
now  known  as  the  Scheduling  Assistance  System,  with  the  cur¬ 
rent  version  (SAS  2.0)  having  been  developed  while*  the 
author  attended  the  Air  War  College. 

While  SAS  2.0  provides  a  useful  set  of  scheduling 
assistance  tools,  a  capability  to  automatically  generate  a 
schedule  was  still  lacking.  Based  on  conversations  with 
several  unit  schedulers,  it  became  obvious  that  satisfying 
the  entire  requirement  established  in  the  Crew  Schedu ling 
System  Functional  Description  was  not  only  unnecessary  and 
unw  ii ranted,  but  would,  in  fact,  actually  hinder  the  sched- 
ul  1  ng  process  as  schedulers  would  become  hamstrung  by  the 
overwhelming  data  input  requirements  of  such  a  system.  What 
was  really  needed  was  a  capability  to  quickly  generate  a 
fairly  good  "first  cut"  quarterly  schedule  which  would  take 
into  account  crew  availability,  sortie  requirements  and 
diversification,  outputting  various  statistics  as  well  as  a 
schedule.  Evaluation  of  the  resultant  schedule  could  then 
be  accomplished  with  the  existing  software.  Fine  tuning  of 
the  schedule  was  felt  to  be  better  left  to  human  insight. 


Based  on  this  idea,  an  algorithm  was  derived  ami  , , 
workable,  albeit  limited,  capab  i  1  1 ty  was  developed  wh i c h 
v  i  1  l  d.i  ted  the  algorithm  and  which  indicated  that,  in  tact,  i 
quite  useful  scheduler  could  be  developed  quickly,  iiu-xpen- 
sively  and  on  even  the  smallest  microcomputer  system.  While 
attending  the  Air  War  College,  the  author  pursued  the  con¬ 
cept  and  developed  the  automated  scheduler  as  SAS  1.0,  a  n 
extension  to  the  redesigned  SAS  2.0. 

The  Concept 

The  main  concept  underlying  the  SAS  3.0  automated 
scheduling  system  is  that  an  effective  aircrew  training 
program  begins  with  a  well  conceived  quarterly  training 
plan.  That  training  plan,  or  quarterly  schedule,  should 
provide  aircrews  with  a  diversification  of  training 
(reflected  by  a  decent  sortie  mix)  which  meets  both  command 
and  wing  directed  training  requirements.  Experience  has 
shown  that  up  to  two  weeks  of  concentrated  effort  by  unit 
schedulers  is  required  to  develop  even  a  "first  cut" 
training  plan,  which  must  then  be  modified  or  fine  tuned  as 
the  quarter  approaches.  This  training  plan,  especially  in 
the  case  of  the  h-52  force,  must  be  developed  in  an  atmos¬ 
phere  of  limited  sortie  production,  thus  making  critical  the 
distribution  of  aircrews  and  sorties,  since  there  are  few 
additional  sorties  available  with  which  to  improve  training 
diversity.  Historically,  the  B-52  force  has  suffered  from 
just  such  a  maldistribution  of  sortie  and  event  activity. 
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Units  which  fail  to  adequately  prep. ire  a  quarterly  t  r  i  i  n  1  n  j 
plan  end  up  s.irjmbl  in«j  throughout  the  execution  quarter. 


"chasing"  traininq  r  eq  u  i  r  ein>  *n  t  s  ,  and  achieving  low  trainin-i 

rates.  Hence  the  SAS  3 .  H  a  u  t  om  1 1  ed  s  c  hed  u  1  e  r  his  . . . 

designed  with  the  SAC  bomber  requirement  in  mind,  i  1  t  tiouqh 
the  concept  can  be  extended  to  the  K  C -  1  3  b  s  e  h  e  d  u  1  i  n  ■  j 
pr  ob  1  em  . 

In  the  case  of  the  bomber  force,  sorties  are  I  iirly 
well  tied  to  the  a  v  a l  1  a  b i  1  l t  y  of  low  level  strategic 
tr  lining  routes  ( ,3  T  K  s )  ,  which  are  "bouqht"  on  a  q  u  a  r  t  •  •  r  1  / 
basis  through  the  STH  scheduling  and  allocation  process.  01 
particular  note  is  the  fact  that  STk  routes  are  al  located 
tor  the  same  time  and  same  day  each  week,  throughout  the 
entire  quarter. 

Mission  packages  are  then  designed  around  the  low 
levels  which  include,  hopefully,  sufficient  night,  fighter, 
cel  1  formation,  navigation,  etc.  activity,  such  that,  given 
a  decent  distribution  of  missions,  each  crew  will  have 
sufficient  opportunity  to  meet  their  training  r eq u l r emon t s . 
Thus  a  standard  week  of  sorties  is  created.  It  is  this 
regularity  which  SAS  3.0  uses  as  a  basis  for  its  quarterly 
schedule  generation. 

What  SAS  Does 

SAS  3.0  a u toma t l ca 1 1 y  generates  a  quarterly  schedule 
of  missions  for  the  flying  wing,  distributing  the  various 
sorties  irnong  tin*  a  l  t  lews.  The  schedule  which  is  produce, ) 


i i  "  I  i  t  (  <  u  (  "  :  ;<  lx  >d  u  I  « * ,  wli  i » ’ll ,  in  .ill  pi  <>1>.  1 1  >  i  1  i  t  y  ,  :;l  i  I  I 
requires  some  tine  tuning.  However,  the  actual  process  of 
creating  that  schedule  is  reduced  from  two  weeks  to  a  matter 
ill  minutes.  The  fine  tuning  process  is  minimal, 
accomplished  within  a  few  hours  at  most. 

Obviously  several  inputs  to  the  program  are  nec¬ 
essary.  These  consist  of  an  alert,  CCKR,  and  leave  sche¬ 
dule;  a  "MASTER  WEEK"  of  sorties;  the  crew  sortie  require¬ 
ment  tor  the  quarter;  and  any  known  "hard"  requirements, 
such  as  higher  headquarters  directed  (HHD)  missions  or  crew 
TDYs.  With  the  exception  of  the  MASTER  WEEK,  such  informa¬ 
tion  is  obtained  from  the  files  created  using  SAS  2.0.  The 
program  which  generates  the  MASTER  WEEK  file,  is  included  in 
the  SAS  3.0  package. 


SAS  3.0  schedules  crews  against  sorties  on  a 
priority  to  fly  basis,  thus  crews  which  may  be  unavailable 
at  the  end  of  the  quarter  due  to  leave,  for  example,  are 
scheduled  at  a  higher  priority  than  other  crews.  Similarly, 
crews  with  minimum  availability  throughout  the  quarter 
(higher  alert,  TDY  commitments)  are  likewise  provided  higher 
priority.  Currently,  priority  to  fly  is  computed  on  the 
number  of  sorties  required  by  the  crew  divided  by  the  number 


of  days  available  remaining  in  the  quarter. 
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Pi  vers  i  f  icat  i _o_n 

SAS  I.t)  attempts  to  maximize  sortie  diversification 
based  on  the  mission  identification  (ID)  number  of  the 
sortie,  the  Low  level  route,  a  sortie  option,  day/night,  and 
up  to  sixteen  user  defined  parameters.  Options  are  provided 
to  disregard  this  built-in  diversification.  Specifically, 
each  mission  in  the  MASTER  WEEK  is  coded  with  a  three  char¬ 
acter  mission  ID.  The  first  character  is  an  '  F '  or  ’  f ' , 
which  designates  the  activity  as  a  flying  mission.  The 
second  character  is  used  to  indicate  the  low  level  route  tor 
that  sortie.  (In  actuaLity,  this  second  character  may  rep¬ 
resent  anything,  such  as  air  refueling  routes  or  type 
receiver  for  tanker  units.)  The  third  character  (optional) 
is  the  sortie  option,  which  can  be  used  to  differentiate 
between  different  sorties  which  may  use  the  same  low  level 
route.  Thus  option  "A"  could  indicate  day,  and  option  "N" 
night.  For  example,  the  mission  ID  " F 3 A "  could  identify  a 
day  sortie  with  day  air  refueling  and  a  cell  navigation  leg, 
whereas  "F3B"  identifies  basically  the  same  sortie,  but  has 
a  fighter  intercept  exercise  added  on. 

Night  diversification  is  achieved  by  identifying  the 
sortie  as  a  "late  lander"  during  construction  of  the  MASTER 
WEEK  file. 

Up  to  sixteen  sortie  parameters  may  be  identified  by 
the  user  which  can  be  used  to  further  diversify  the  aircrew 
training.  Of  special  note,  these  parameters  provide  an  easy 
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way  of  diversifying  such  items  as  fighter  activity,  cel  L 


formation,  MITO,  high  bombing,  etc.  SAS  1.0  is  obi  lvious  to 
what  the  parameters  specifical Ly  mean,  but  it  does  attempt 
to  diversify  sorties  among  crews  based  on  these  parameters, 
and,  of  particular  use  to  the  scheduler,  provides  a  listing 
of  the  diversification  of  these  parameters  at  the  completion 
of  its  schedule  generation. 

Diversification  is  achieved  by  examining  the  MASTER 
WEEK  and  computing  the  ratio  of  different  mission  IDs,  low 
level  routes,  sortie  options,  night,  and  each  parameter  to 
the  total  availability  of  such  items  in  the  MASTER  WEEK. 
This  ratio  is  then  applied  against  each  crew's  sortie 
requirement  and  an  "ideal"  number  of  each  item  is  computed 
for  that  crew.  If  this  "ideal"  number  is  exceeded  in  any 
category,  the  crew  will  not  be  scheduled  for  a  particular 
sortie,  except  when  it  is  the  only  crew  available  which 
could  fly  the  particular  sortie  (even  this  feature  can  be 
turned  off  and  the  sortie  left  unfilled). 

Scheduling  Rules 

When  building  a  schedule,  SAS  3.0  adheres  to  certain 
common  rules  and  desires  of  the  operations  and  training 
community.  Specifically,  SAS  3.0  will  not  schedule  a  crew 
for  the  same  mission  twice  in  a  row,  or  even  the  same  low 
level  route  twice  in  a  row,  except  as  a  last  resort  (i.e., 
the  only  crew  available).  SAS  3.0  will  not  schedule  a  crew 
to  exceed  its  "ideal"  diversification  as  described  above, 
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except  as  a  last  resort.  Crews,  scheduled  lot  alert,  TOY  ■ . 
Leave  the  following  day,  will  not  be  scheduled  Lor  sortie, 
which  Land  Later  than  the  unit's  Local  ly  determined  i.mdin; 
time  for  such  cases.  Crews  will  not  be  scheduled  to)  lowino 
CCRR  for  sorties  which  take  off  prior  to  the  unit's  local 
time  for  this  situation.  Crews  will  not  be  scheduled  uni  os; 
the  day  preceding  is  available  Lor  mission  planning.  SAS 
3.0  will,  however,  allow  holidays,  weekends,  and  CCRR  to 
come  between  the  designated  mission  planning  day  and  the  day 
of  the  mission.  In  the  case  of  CCRR,  the  last  day  of  alert 
will  be  designated  as  the  mission  planning  day.  Even  when 
sorties  are  identified  as  being  capable  of  being  mission 
planned  and  flown  on  the  same  day,  SAS  3.0  will  only 
schedule  a  crew  to  mission  plan/fly  the  same  day  if  no 
preceding  mission  planning  day  is  available  and  no  other 
crew  is  available. 

The  "last  resort"  feature  refers  to  the  fact  that 
sometimes  one  of  the  desires  or  rules  above  may  have  to  be 
violated  in  order  to  fill  a  sortie.  In  terms  of  SAS  3.0, 
this  is  referred  to  as  AUTOFILL,  i.e.,  a  crew  will  not  be 
scheduled  to  fly  a  sortie  if  it  violates  any  of  these  rules, 
unless  no  other  crew  can  be  found  to  fly  the  sortie  which 
itself  does  not  violate  one  or  more  of  the  rules.  This 
AUTOFILL  feature,  normally  ON,  can  be  turned  OFF  and  the 
sortie  left  unfilled.  In  addition,  each  of  the  rules  above 


can  be  suspended. 


What  SAS  Does  Not  Do 


While  the  Scheduling  Assistance  System  does  provide 
the  unit  aircrew  scheduler  with  a  variety  ot  tools  to  en¬ 
hance  the  scheduling  process,  it  is  not  a  panacea.  SAS  will 
not  and  can  not  reduce  manpower,  its  purpose  is  to  enhance 
the  effectiveness  of  the  scheduling  process  by  automating 
certain  manual,  time  consuming,  repetitive  functions. 

SAS  3.0  only  schedules  entire  aircrews,  not  indivi¬ 
dual  aircrew  members,  hence  such  important  items  as  flight 
physicals  and  ground  training  requirements  still  require 
manual  scheduling.  In  the  same  vein,  crews  with  missing 
crew  members  are  treated  as  if  they  were  complete  crews, 
substitution  for  non-mission  ready  or  absent  crew  members 
also  requires  manual  scheduling.  (Incidentally,  AFORMS  does 
have  some  capability  to  identify  the  availability  of  indivi¬ 
dual  crew  members.) 

SAS  3.0  does  not  schedule  alert,  CCRR,  leave,  or  any 
ground  requirements  (other  than  mission  planning).  All  such 
activity  must  be  manually  scheduled.  In  actual  practice  the 
quarterly,  and  even  annual,  scheduling  of  alert,  CCRR  and 
leave  does  not  appear  to  be  a  major  problem  at  the  crew 
level.  Individual  substitutions  for  alert  and  leave  is 
another  issue. 

As  currently  programmed,  SAS  3.0  generates  only  a 
full  three  month  quarterly  schedule.  It  is  not  capable  of 
r-schedu  I  ing  the  remainder  of  the  quarter  from  some  point 
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later  on  in  the  quarter.  This  eapab  1  l  lty  could  be  adclt-d 


with  minimal  r epr og r a mm i ng . 


SAS  1.0  is  qeared  to  sehedu  1  inq  sorties  hasvd  on  .1 


MAST  P.  K  WKKK.  While  this  makes  a  qreat  deal  of  sense  in  t  h. 


number  world,  many  tanker  sorties  are  not  necessarily  tasked 


on  a  weekly  basis.  Although  not  explored  in  detail,  1 


appears  that  SAS  3.0  could  be  modified  relatively  easi !y  t 


handle  a  quarterly  sortie  flow  as  input,  rather  than  just  a 


week  1 y  flow. 


SAS  3.0  will  not  develop  mission  profiles.  T  r 


scheduler  or  mission  developer  must  build  the  actual  mission 


packages  themselves.  The  SAS  2.0  system  will,  however, 


evaluate  the  training  shortfalls  of  a  schedule  built  on 


those  sorties.  Thus  the  scheduler  is  provided  with  a  hard¬ 


copy  product  from  which  changes  to  mission  profiles  can  be 


made  to  ensure  that  sufficient  opportunity  exists  in  which 


to  complete  the  training  requirements. 


As  of  now,  the  user  is  required  to  use  SAS  2.0  t 


develop  the  data  bases  required  of  the  SAS  3.0  automated 


scheduling  function.  Similarly,  once  a  schedule  has  been 


created,  it  can  only  be  printed  and  evaluated  by  returning 


to  SAS  2.0.  This  inconvenience  is  simply  due  to  the  time 


available  to  the  author  to  reprogram  the  entire  SAS  2  .?■ 


program  set. 


Perhaps  the  major  deficiency  of  both  SAS  program 


sets  is  in  its  standalone  nature,  without  interface  to 
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AFORMS.  WhiLe  this  is  easiLy  remedied  and  well  within  the 
capabilities  of  HQ  SAC,  it  does  require  a  commitment  of  HQ 
SAC/SI  computer  programmer  resources  and  HQ  SAC/DO  func¬ 
tional  area  cooperation  and  design  analysis.  As  it  now 
stands,  SAS  has  to  maintain  several  data  files  which  only 
duplicate  files  which  exist  in  AFORMS,  as  a  result  needless 
data  input  duplication  is  required. 

Hardware  and  Software  Requirements 

Both  SAS  systems  (2.0  and  3.0)  have  been  designed  to 
operate  under  the  CP/M  operating  system  with  a  minimum  of 
6  4  K  memory,  a  printer  and  two  disc  drives.  An  MS-DOS 
version  is  under  development. 

While  the  bulk  of  the  SAS  program  set  (version  2.0) 
was  programmed  in  CBASIC,  the  automated  scheduler  programs 
(SAS  3.0)  were  written  in  'C',  due  to  its  greater  efficiency 
and  reduced  memory  requirement.  A  file  conversion  program  is 
provided  to  maintain  compatabi 1 i ty  between  the  two  versions. 
Eventually,  it  is  the  author's  intent  to  convert  the  SAS  2.0 
programs  to  'C'  and  the  SAS  3.0  file  structure. 


CP/M  is  a  registered  trademark  of  Digital  Research  Corp. 
MS  is  a  trademark  of  Microsoft  Corporation. 

CBASIC  is  a  trademark  of  Compiler  Systems,  Inc. 


CHAPTER  VI 


CONCLUS I  ON  S 

The  combat  capability  of  Strategic  Air  ■‘orainia: 
aircrews  is  to  a  large  extent  determined  by  the  qualify  : 
their  training,  which  is  directly  controlled  by  the  ain't 
scheduling  process.  The  major  component  of  SAC  s  cornea' 
power,  the  B-52  force,  suffers  from  relatively  low  trinnr,  : 
rates.  While  several  diverse  factors  contribute  to 
state,  they  all  come  together  during  the  development  >! 
flying  schedule.  Subsequently,  improvements  in  the  air. Tew 
scheduling  process  should  translate  directly  to  improve: 
training  and  combat  readiness. 

Due  to  the  complexities  of  the  scheduling  process 
and  the  enormous  number  of  individual  data  elements  which 
must  be  managed  and  analyzed,  automated  support  is  mandated. 
Existing  computer  systems,  such  as  AFORMS,  perform  essential 
bookkeeping  functions,  but  are  not  designed  nor  capable  of 
producing  or  evaluating  the  effectiveness  of  aircrew 
training  schedules. 

A  major  SAC  effort,  intitiated  in  1979,  to  apply 
automation  to  the  schedule  generation  and  evaluation 
functions  has  been  unsuccessful  to  date.  The  effort  did  not 
fail  because  it  was  too  difficult  or  too  expensive.  The 
project  failed  for  such  rather  simple  reasons  as  failing  to 
involve  experienced  schedulers  in  the  definition  and  design 


phases,  tillin')  to  identity  the  problem,  ond  failing  t:o 
assign  responsibility,  accountability  and  authority  for 
m.inagemen  t:  ot  the  project. 

A  u  t  i  >  in  1 1  •  ■  <  i  hod  u  I  <  ■  ■  )<  -  lie  i  1 1  i  <>  n  a  ml  evaluation  is 
quite  feasible  and  relatively  inexpensive.  This  has  been 
demonstrated  by  the  development  of  the  Scheduling  Assistance 
System.  This  set  of  automated  tools  allows  a  scheduler  to 
rapidly  generate  aircrew  training  plans,  evaluate  them,  and 
make  necessary  sortie  and  training  adjustments  early  in  the 
schedule  development  cycle.  This  facilitates  more  effective 
training  and  increased  schedule  stability. 

Using  the  scheduling  and  programming  concepts  of  the 
Scheduling  Assistance  System  as  a  model,  a  comprehensive, 
integrated,  inex pens ive  package  of  automated  scheduling 
tools  can  be  developed  and  fielded  command-wide  in 
relatively  short  order.  The  payoff  in  terms  of  training 
effectiveness  and  combat  capability  warrant  the  pursuit  of 
such  an  effort  within  the  Strategic  Air  Command. 
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CHAPTER  IV  (Pages  18-22) 

1.  During  1984  SAC  established  a  now  deputate,  ‘.In- 
Deputy  Chief  of  Staff,  Information  Services  (SI)  which 
combined  two  previous  deputates.  Communications  and  Dai  . 
Services  (AD).  In  general,  an  office  previously  identified 
as  ADUP  became  known  as  SIUP  under  this  latest 
reorgan i zat ion . 
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Airborne  Command  Control  Squadron 


Deputy  Chief  of  Staff,  Data  Services 


Director  of  Computer  Applications 


Air  Force  Bast 


Air  Force  Operations  Resource  Management  Syst 


Air  Launched  Cruise  Missile 


Aircrew  Training  Report 


Strategic  bomber  aircraft 


Combat  Crew  Rest  and  Recuperation 


Command  Directed  Event 


Cathode  Ray  Tube 


Data  Automation  Requirement 


Duty  Not  Involving  Alert 


Duty  Not  Involving  Flying 


Deputy  Chief  of  Staff,  Operations 


Director  of  Training 


Operations  Systems  Management  Division 


Training  Management  Information  Branch 


Training  Division 


A  command  and  control  aircraft  for  use  by  the 
National  Command  Authority.  Also  known  as  the 
National  Emergency  Airborne  Command  Post. 


A  command  and  control  aircraft  used  as  an 
airborne  command  post  for  SAC.  Also  known  as 
the  "Looking  Glass." 


A  medium  range  strategic  bomber  aircraft. 
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Functional  Description. 

Flying  Program  Document 
llighei  llenilqu.i  r  I  ei  s  Directed 
1 1  •  >  u  d  q  u  a  rtecs 

Individual  Completion  Rate 
Iden  1 1  f  i cat  ion 
K  i  loby te 

Strategic  tanker  aircraft 
Major  Command 
Minimum  Interval  Take  Off 
Monthly  Operations  Plan 
Noncomm iss i onod  Officer 
Offensive  Avionics  System 
Operations  Systems  Management 
Personal  Computer 
Strategic  Air  Command 

SAC  Aircrew  Resource  Management  System 
SAC  Regulation 

Scheduling  Assistance  System 

Deputy  Chief  of  Staff,  Information  System 

Support  Programming  Division 

Strategic  Reconnaissance  Wing 

Strategic  Training  Route 

Temporary  Duty 

Wing  Directed  Event 


